Thorsten,
You are correct as usual. I ran Mr Suszuki's carpet and tori example and we get:

55.3%  ==> POVFPU_RunDefault
7.7%    ==> drem.c library function
6.0%    ==> Noise
2.8%    ==> __itrunc
2.0%    ==> f_noise3d
1.7%    ==> sqrt
1.6%    ==> IsoSurface_Function_Find_Root_R
1.5%    ==> POVFPU_SetLocal

Then a pile of functions out of the math library running around 0.5 to 1.2%.

I have looked over the POVFPU_RunDefault code and I find it both impressive and
intimidating. I just don't understand it well enough to help. I do wonder how
well the compilers are optimizing that huge case statement.  10 years ago case
statements of that size were trouble for a compiler and breaking them up with
conditionals was recommended. But, I do not know if this holds for the compilers
of today or even if it would be possible to break this case statement up....
Bill P.


> "ABX" <abx### [at] abxartpl> schrieb im Newsbeitrag
> news:he4umukt09felolvnem4jui7g6r2bu09nq@4ax.com...
> > On Thu, 29 Aug 2002 16:57:45 -0400, "William F. Pokorny"
> > <pok### [at] attglobalnet> wrote:
> > > 29.3%  ==> POVFPU_RunDefault
> > > 12.1%  ==> Evaluate_Function_UV
> > > 11.7%  ==> POVFPU_SetLocal
> >
> > Something to think about. Thanks.
>
> But not much to do about ... the ratio will actually change depending on the
> functions used.  The more complex the more POVFPU_RunDefault will consume,
> while the other two will sooner or later be irrelevant.  One should really
> not measure these with trivial functions which only contains something
> simple like sin or cos, but more complex functions using some operations...
>
>     Thorsten

Post a reply to this message